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Response to Amendment 

Applicant's arguments filed on September 09, 2008 have been fully considered 
but are not deemed persuasive. 

Response to Arguments 

In essence the Applicant argues "...that Adelman does not teach or suggest the 
feature of sending the keepalive period in a response to a received keepalive 
message" (pages 3-4). 

The Examiner disagrees. For example, Adelman teaches calculating adaptive 
keepalive period based on the received client keepalive message (col. 8, lines 
15-23 and col. 13, lines 20-41). 

Adelman further teaches The "client keepalive" packets contain a monotonically 
increasing sequence number which is used to measure packet loss in the 
system and to adjust the probability of packet loss value which is used to 
adjust the adaptive keepalive interval (col. 13, lines 32-36). Adelman also 
teaches "Each client includes a sequence number in its "client keepalive" 
packet. When the master gets this keepalive packet for client "x" he makes the 
following calculations: ... The resulting value of "n" is the adaptive keepalive 
interval which the master then sends to all of the cluster members to use in 
determining how often they are to send their "Client keepalive" message. "(Col. 
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13, lines 42 to col. 14, lines 13). Therefore, Adelman's sending the calculated 
keepalive period is based on received client keepalive message. 

The Applicant admits that "Adelman teaches that master and client devices are 
each arranged to periodically send keepalive message to each other. When a 
client sends a keepalive message to the master, the master determines packet 
loss and establishes a new keepalive interval ." page 4 second paragraph, but 
argues "However, Adelman does not teach that the master sends that new 
keepalive interval in a response to the keepalive message received from the 
client." There is no such limitation of sending new keepalive interval in 
response to keepalive message in the claims." The examiner maintains that 
Adelman's teaching of calculating adaptive keepalive period based on the 
received client keepalive message as explained above meets the argued 
limitation. 

• Claims 1-17 and 19-26 are presented for examination. 

Claim Rejections - 35 USC §103 

The following is a quotation of 35 U.S. C. 103(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject 
matter sought to be patented and the prior art are such that the subject matter as a whole 
would have been obvious at the time the invention was made to a person having ordinary 
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skill in the art to which said subject matter pertains. Patentability shall not be negatived by 
the manner in which the invention was made. 

Claims 1,3, 4, 7-10, 13, 14-15, 19,25, and 26 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Adelman et al. (US 6078957), 
hereinafter "Adelman" in view of Fleming US PUB. (20020152446). 

As per claims 1 and 3, Adelman teaches a method comprising: 

receiving a keepalive message from a client (col. 8, lines 14-16 and col. 9, 
lines 3-5); 

determining a measure of network load (packet loss is a measure of 
network load that is determined by the master, "... master calculates and 
stores a packet loss average value using the sequence number of the client 
keepalive message and the calculated adaptive keepalive interval." column 8, 
lines 15-23); 

selecting a keepalive period (based on packet loss, an adaptive keep alive 
period is calculated," ... the master calculates and stores a packet loss average 
value using the sequence number of the client keepalive message and the 
calculated adaptive [i.e. changes the ] keepalive interval", column 8, lines 20- 
23); 

reporting the selected keepalive period to the client station in a response 
to the received keepalive message (keepalive periods are calculate and reported 
to clients based on received keepalive messages from the client column 8, lines 
31-33 and column 13, line 42 to col. 14 lines 3); and 
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the client station responsively sending a keepalive message to a presence 
server at a time determined based on the selected keepalive period (client sends 
keep alive messages with updated adaptive keepalive interval, "The non-master 
cluster members (clients) must also send keepalive message and ..." Column 9, 
lines 2-3 in conjunction with, "... when a client gets a master keepalive 
message 890 it updates its adaptive keepalive interval 891 Column 9, lines 
4-6). 



Although Adelman shows substantial features of the claimed invention 
including selecting a keepalive period on measure of packet loss, he does not 
explicitly show where the keepalive period is based on network load. 
Nonetheless, this feature is well known in the art and would have been an 
obvious modification of the system disclosed by Adelman, as evidenced by 
Fleming. 

In analogous art, Fleming disclose adjusting heartbeat timeouts (keepalive 
period) based on observed conditions such network congestions (abstract and 
paragraph 0024). Giving the teaching of Fleming, a person of ordinary skill in 
the art would have readily recognized the desirability and the advantage of 
modifying Adelman by employing the adaptive heartbeat system of Fleming in 
order to adaptively adjust heartbeat timeouts (keepalive) based on to observed 
network conditions. In this way proper corrective action can be taken to 
minimize potential network failures. 
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Adelman further teaches the presence server (cluster master, which is also 
cluster member, "... each of the cluster members is a computer system...", 
column 5, line 22; acting as master) querying a controller (has controller, "... 
and two Intel Ethernet controllers," column 5, line 24) that has access to 
network load information (FIG. 1 in conjunction with FIG. 4, FIG. 1 Item 1 10 is 
the cluster one ether net connected to other network units. To get the sequence 
number master must have queried and obtained the packet from the Ethernet 
controller.). 

For Claim 4: A presence server (master of the cluster) in a communication 
network (see FIG. 1, item 110, in conjunction with column 5, line 16-17, "...will 
be described as a cluster whose applications may be VPN tunnel...", which 
indicates that FIG. 1, Item 1 10 is a cluster), comprising: 

a first module (see FIG. 8B, item 830, a module) arranged to 
receive keepalive messages from at least one client station (master got client 
keepalive); a second module (a second module, see FIG. 8B, item 835) arranged 
to select a keepalive period (FIG. 8B, Item 835, "CALCULATE AND STORE 
PACKET LOSS AVERAGE (USING SEQUENCE NUMBER OF KEEP ALIVE AND 
ADAPTIVE KEEPALIVE INTERVAL)", Packet average loss is the measure of 
network load, and adaptive keepalive interval is keepalive period based on 
network load); a third module (FIG. 8C, item 851) arranged to report the 
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selected keepalive period to the at least one client station (FIG. 8C, item 851, 
"BROADCAST MASTER KEEPALIVE CONTAINING CLUSTER MEMBER LIST 
AND ADAPTIVE KEEPALIVE INTERVAL"). 

As to the keepalive period being based on network load see the rejection on 
claim 1 and 3 above. 

For claim 7: The presence server of claim 4 (see supra for claim 4 discussion), 
wherein the presence server is coupled to a controller (a master which is also 
cluster member has two Ethernet controllers, "each of the cluster members is a 
computer system having an Intel motherboard, two Intel Pentium processors, a 
64 megabyte memory and two Intel Ethernet controllers,..."), the controller 
keeping track of network load information (the controller receives the packets, 
therefore controller keeps track of packet sequence numbers, which in turn 
determine network packet loss-network load, "... when the master gets a 'client 
keepalive message' (that is one from a non-master cluster member) 830 ... 
master calculates and stores a packet loss average value using sequence 
number of the client keepalive message and the calculated adaptive keepalive 
interval.", Column 8, lines 15-23). 

For claim 8: The presence server of claim 4 (see supra for claim 4 discussion), 
wherein the presence server is embedded with a controller (a master which is 
also cluster member has two Ethernet controllers that are present on the 
mother board or attached to mother board, i.e. they are embedded, "each of the 
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cluster members is a computer system having an Intel motherboard, two Intel 
Pentium processors, a 64 megabyte memory and two Intel Ethernet 
controllers.... ") that keeps track of network load information (the controller 
receives the packets with packet sequence number, therefore controller keeps 
track of packet sequence numbers, which in turn determine network packet 
loss, which is a measure of network load, "... when the master gets a 'client 
keepalive message' (that is one from a non-master cluster member) 830 ... 
master calculates and stores a packet loss average value using sequence 
number of the client keepalive message and the calculated adaptive keepalive 
interval.", column 8, lines 15-23). 

For claim 9: Adelman teaches a system comprising: 

at least one client station (FIG. 4, Items 405-409 as non-master cluster 
members); a presence server (Master acting as presence server and for 
description of master formation please refer to FIG. 6 - 8A, in conjunction with 
reference to column 6, line 40 - column 8, line 13); the presence server 
receiving a keepalive message from the at least one client station (col. 8, lines 
14-16 and col. 9, lines 3-5); 

the presence server determining a keepalive period (keepalive period is 
determined by master based on packet loss, which is a measure of network 
load, "... when the master gets a 'client keepalive message' (that is one from a 
non- master cluster member) 830 ... master calculates and stores a packet loss 
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average value using sequence number of the client keepalive message and the 
calculated adaptive keepalive interval.", column 8, lines 15-23) based on 
network load (packet loss rate is a measure of network load) and sending an 
indication of the keepalive period to the at least one client station in a response 
to the keepalive message (col. 13, lines 42 to col. 14, lines 13)(FIG. 8C, item 
851, "BROADCAST MASTER KEEPALIVE CONTAINING CLUSTER MEMBER 
LIST AND ADAPTIVE KEEPALIVE INTERVAL"); 

the at least one client station sending keepalive signals according the 
keepalive period (See FIG. 8H, Item 912, "SEND CLIENT KEEP ALIVE TO 
MASTER CONTAINING MONOTONICALLY INCREASING SEQUENCE # (FOR 
MEASURING NETWORK PACKET LOSS" in conjunction with column 9, lines 
13-17, "Each client also has a periodic timer which is adaptive to the network 
packet loss value send by the master which requires the client to send a client 
keepalive message (containing a monotonically increasing numeric value) to the 
master periodically"). 

As to the keepalive period being based on network load see the rejection on 
claim 1 and 3 above. 

For claim 10: The system of claim 9 (see supra for claim 9 discussion), further 
comprising a controller that has access to network load information (FIG. 1 in 
conjunction with FIG. 4, FIG. 1 Item 110 is the cluster one ether net connected 
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to other network units. To get the sequence number master must have queried 

and obtained the packet from the Ethernet controller.). 

For claim 13: The communication network of claim 9 is a packet- switched 

network (see FIG. 1, Item 1 10 the cluster connecting to internet 107 through 

communication link 109, It is well known that internet is a packet- switched 

network). 

For claims 14 and 15: A method comprising: sending a first keepalive message 
from a client station to a presence server (FIG. 8B, Item 830, "MASTER [master 
is presence server] GOT CLIENT KEEPALIVE"); selecting a keepalive period 
based on a measure of network load (FIG. 8B, item 835, "CALCULATE AND 
STORE PACKET LOSS AVERAGE (USING SEQUENCE NUMBER OF 
KEEPALIVE AND ADAPTIVE KEEPALIVE INTERVAL", the packet loss average is 
network load and keepalive period is changed based on this load)"; reporting 
the selected keepalive period to the client station" (FIG. 8C, "BRAODCAST 
MASTER KEEPALIVE CONTAINIGN CLUSTER MEMBER LIST AND ADAPTIVE 
KEEPALIVE INTERVAL"); using the selected keepalive period to determine when 
the client station should send a next keepalive message to the presence server 
(See FIG. 8H, Item 912, "SEND CLIENT KEEP ALIVE TO MASTER CONTAINING 
MONOTONICALLY INCREASING SEQUENCE # (FOR MEASURING NETWORK 
PACKET LOSS" in conjunction with column 9, lines 13-17, "Each client also 
has a periodic timer which is adaptive to the network packet loss value sent by 
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the master ..."); sending the next keepalive message from the client station to 
the presence server (client, i.e. non-master sends the keep alive message to 
master, i.e. presence server, "... which requires the client to send a client 
keepalive message (containing a monotonically increasing numeric value) to the 
master periodically (see FIG. 8H) [item 912].", column 9, lines 14-17). 
As to the keepalive period being based on network load see the rejection on 
claim 1 and 3 above. 

For claim 19: Adelman teaches a client station (Cluster member as described in 
column 5, lines 22) in a communication network (see FIG. 1 Item 107), the 
client station comprising: a receiver (column 5, line 24, "... two Ethernet 
controllers", which implies a ether net phy with a receiver); a transmitter 
(column 5, line 24, "... two Ethernet controllers", which implies a ether net phy 
with a transmitter); a timer (column 9, lines 13-16, "Each client also has a 
periodic timer which is adaptive to the network packet loss value sent by the 
master which requires the client to send a client keepalive message ..."); at 
least one processor(column 5, line 22, "... two Intel Pentium processors"); data 
storage holding program instructions (FIG. 2, Item 217, CD-ROM medium in 
conjunction with column 4, line 42, "... a CD-ROM drive unit 217. The CD- 
ROM drive unit 217 can read a CD-ROM medium 219 which typically contains 
program 221 ...",); the program instructions being executable by the at least 
one processor to send a keepalive message through the transmitter, and to 
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receive through the receiver a response to the keepalive message, the response 
containing information defining a keepalive period, the keepalive period being 
selected based on network load (column 9, lines 13-16 and col. 13, lines 42 to 
col. 14, lines 13); and 

the program instructions being executable by the at least one processor, 
in response to receiving information defining a keepalive period wherein the 
keepalive period is selected based on network load (column 9, lines 13-16, 
"Each client also has a periodic timer which is adaptive to the network packet 
loss value [network packet loss value is a measure of network load) sent by the 
master which requires the client to send a client keepalive message ..."), to: (i) 
set the timer according to the keepalive period(column 9, lines 13-16, "Each 
client also has a periodic timer which is adaptive to the network packet loss 
value [network packet loss value is a measure of network load) sent by the 
master which requires the client to send a client keepalive message ..."); (ii) 
send a new keepalive message through the transmitter when the timer expires 
(column 9, lines 13-16, "Each client also has a periodic timer which is adaptive 
to the network packet loss value [network packet loss value is a measure of 
network load) sent by the master which requires the client to send a client 
keepalive message ..."). 

As to the keepalive period being based on network load see the rejection on 
claim 1 and 3 above. 
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For claim 25: A presence server in a communication network comprising: a 
database, the database maintaining a list client stations that are connected to 
the network (column 8, lines 31-33, "As indicated above the master periodically 
sends out a master keepalive message containing the cluster member list 
since cluster member list is being sent, they must be stored in a database); a 
timer (column 9, lines 13-16, "Each client also has a periodic timer which is 
adaptive to the network packet loss value sent by the master which requires 
the client to send a client keepalive message ..."); wherein the presence server 
(master is the presence server) is programmed to: receive keep alive messages 
from at least one client station (See FIG. 8B, item 830, "MASTER GOT CLIENT 
KEEPALIVE"), select a keepalive period for the at least one client station based 
on a measure of network load (FIG. 8B, Item 835, "CALCULATE AND STORE 
PACKET LOSS AVERAGE (USING SEQUENCE NUMBER OF KEEPALIVE AND 
ADAPTIVE KEEPALIVE INTERVAL", where packet loss average is measure of 
network load based on which keepalive interval is determined.), report the 
selected keepalive period to the at least one client station in a response to the 
received keepalive message (col. 13, lines 42 to col. 14, lines 13) (FIG. 8C, item 
851, "BORADCAST MASTER KEEPALIVE CONTAINING CLUSTER MEMBER 
LIST AND ADAPTIVE KEEPALIVE INTERVAL"), and drop the at least one client 
station from the database (FIG. 8E, ITEM 871, "DELETE CLIENT FROM 
CLUSTER DATA STRUCTURE") if the presence server does not receive new 
keepalive message within the selected keepalive period from the at least one 
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client station (FIG. 8E, ITEMS 870, WATCHDOG TIMER FOR A CLIENT 
EXPIRES", which means presence server did not receive a keepalive message 
from the client.). 

As to the keepalive period being based on network load see the rejection on 
claim 1 and 3 above. 

For claim 26: A method comprising: sending a first keepalive message from a 
client station to a presence server (See FIG. 8B, item 830, "MASTER GOT 
CLIENT KEEPALIVE", which means client must have sent a keepalive 
message); selecting a keepalive period based on a measure of network load 
(FIG. 8B, Item 835, "CALCULATE AND STORE PACKET LOSS AVERAGE 
(USING SEQUENCE NUMBER OF KEEPALIVE AND ADAPTIVE KEEPALIVE 
INTERVAL", where packet loss average is measure of network load based on 
which keepalive interval is determined.); reporting the selected keepalive period 
to the client station in a response to the first keepalive message (col. 13, lines 
42 to col. 14, lines 13) (FIG. 8C, item 851, "BORADCAST MASTER KEEPALIVE 
CONTAINING CLUSTER MEMBER LIST AND ADAPTIVE KEEPALIVE 
INTERVAL"); using the selected keepalive period to determine when the client 
station should send a next keepalive message to the presence server (FIG. 8B, 
item 837, ".RESET WATCHDOG FOR THIS CLIENT", when this timer expires, 
i.e. with in adaptive keepalive interval if client does not send a keepalive 
message, client will be removed) ; updating a database of the presence server 
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based on whether the client station has sent a next keep keepalive message to 
the presence within the selected keepalive period (FIG. 8E, item 870, 
WATCHDOG TIMER FOR CLINET EXPIRES", if keepalive message is received 
by master it watchdog timer would have been reset, See FIG. 8B, item 837 in 
conjunction with item 830). 

As to the keepalive period being based on network load see the rejection on 
claim 1 and 3 above. 

5. Claims 2, 6, 12, 17, are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman and Fleming et al. in view of Harsch (US 6212175 
Bl). 

For claims 2, 6, and 12 Adelman et al and Fleming teach everything except 
client being wireless mobile workstation, or presence server present in wireless 
communication network. The general concept of client being wireless 
workstation or presence server being present in wireless communication 
network is well known in the art as shown in Figure 1 use of MOBILE UNIT as 
client or presence server being present in a wireless network as indicated by 
Harsch (see the Figure 1, items 66, 66a, 66b, etc., which are mobile units 
which are present in a wireless communication network (see item 67 indicating 
being wireless antenna) and presence server being Item 60, Host computer 
(Harsch)). It would have been obvious to one in skilled in the art at the time of 
the invention to modify Adelman et al and Fleming to have a wireless mobile 



Application/Control Number: 1 0/667,88 1 Page 1 6 

Art Unit: 2456 

workstation and presence server in a wireless communication network in order 
to sustain TCP connection as taught in Harsch (see title, "METHOD TO 
SUSTAIN TCP CONNECTION"). 

For claim 17, Adelman et al teaches all the limitations of claim 17 except 
serving one or more wireless mobile subscribers in a wireless communication 
system. The general concept of serving one or more wireless mobile subscribers 
in a wireless communication system is well known in the art as illustrated by 
Harsch (FIG. 1, items 66, 66a, and 66b, several mobile units serving various 
subscribers in a wireless communication system). It would have been obvious 
to one in skilled in the art at the time of the invention to modify Adelman et al 
to serving one or more wireless mobile subscribers in a wireless 
communication system in order to serve various mobile stations in a wireless 
communication system as taught in Harsch (see FIG. I, serving various mobile 
units items 66, 66a, and 66b in a wireless communication network as shown 
in FIG. 1). 

5. Claims 20, 22 and 24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman and Fleming et al. in view of Harsch (US 6212175 
Bl). 

For claim 20: A system for dynamically determining keepalive periods in a 
wireless communication network, comprising: at least one base station (this 
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claim limitation is not taught); at least one client station (FIG. 4, Items 405-409 
as non-master cluster members); a presence server (FIG. 4, Item 403 as 
master, acting as presence server); A packet switched network (see FIG. 4, 
Items 411 and 107, INTERNET is known to be packet switched network); The 
presence server (master, which will be one of items 403-409) being capable of 
communicating with at least one client station (All items 403-409 which is not 
master are clients) through the packet-switched network (FIG. 8B, item 830, 
"MASTER GOT CLIENT KEEPALIVE", since keepalive is a packet, it is implicit 
that there must be packet- switched network); the presence server determining 
a keepalive period (keepalive period is determined by master based on packet 
loss, which is a measure of network load, "... when the master gets a 'client 
keepalive message' (that is one from a non- master cluster member) 830 ... 
master calculates and stores a packet loss average value using sequence 
number of the client keepalive message and the calculated adaptive keepalive 
interval.", column 8, lines 15-23) at least one mobile subscriber (this claim 
limitation is not taught by Adelman et al) based on network load (packet loss 
rate is a measure of network load) and the presence server reporting the 
selected keepalive period (FIG. 8C, item 851, "BROADCAST MASTER 
KEEPALIVE CONTAINING CLUSTER MEMBER LIST AND ADAPTIVE 
KEEPALIVE INTERVAL") to the at least one mobile subscriber (this limitation is 
not taught by Adelman et al) through the packet-switched network (see FIG. 4, 
Items 411 and 107, INTERNET is known to be packet switched network); 
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Adelman et al teaches all the claim limitations as discussed above except for 
coupling a mobile client(s) through a base station to a packet switched network 
server. The general concept of coupling mobile user through a base station to a 
packet switched network server is well known in the art as illustrated by 
Harsch (see FIG. 1, items 66, 66a, and 66b mobile stations, coupled to server 
(host computer) through bases station 54a, wired line 52 (see page 4, Para 
0037, lines 4-6, "The network backbone 52 may be a hardwired data 
communication path made of twisted pair cable, shielded coaxial cable or fiber 
optic cable, ...") to item 60, host computer). It would have been obvious to one 
in skilled in the art at the time of the invention to modify Adelman et al to 
couple mobile client(s) through a base station in order to make mobile units to 
be part of a cluster as taught in Harsch and Adelman (Harsch: see FIG. 1, 
mobile units 66, 66a, and 66b connected to ° host computer, 60; Adelman: 
FIG. 8F, showing joining of client into a cluster.). For claim 22: The system of 
claim 20 (see supra for claim 20 discussion), wherein the presence server 
(cluster master, which is also cluster member, "... each of the cluster members 
is a computer system column 5, line 22; acting as master) determines 
measures of network load (determined by using the sequence number of 
keepalive and keepalive interval, Adelman: see FIG. 8C, item 835; sequence 
number is the only variable to determine the network load.) by querying a 
controller that has access a measure of network load (FIG. 1 in conjunction 
with FIG. 4, FIG. 1 Item 1 10 is the cluster one ether net connected to other 
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network units. To get the sequence number master must have queried and 
obtained the packet from the Ethernet controller.). 

As to the keepalive period being based on network load see the rejection on 
claim 1 and 3 above. 

For claim 24: The system of claim 20 (see supra for claim 20 discussion), 
wherein the at least one mobile subscriber (after Harsch modification of 
alderman as discussed supra, mobile station is non-master client) upon 
receiving the selected keepalive period (Adelman: FIG. 8G, Item 890, "CLIENT 
GOT MASTER KEEPALIVE"), sends the next keepalive message at a time 
determined by the selected keepalive period Item 891, "UPDATE ADAPTIVE 
KEEPALIVE INTERVAL (CALCULATED BY MASTER)", updating the keepalive 
interval has the effect of sending the next keepalive message according to the 
updated keepalive interval.). 

6. Claims 5 and 1 1 are rejected under 35 U.S. C. 103(a) as being unpatentable 
over Adelman et al and Fleming in view of Rashid et al (US 2004/0230661). 

For Claim 5 and 1 1 Adelman et al and Fleming teach all the claim limitations 
except for polling (polling for claim 5) and pushing (for claim 1 1) the network 
load information. The general concept of pushing and polling information is 
well known in the art as shown in Figure 3, following item 302 to decide 



Application/Control Number: 1 0/667,88 1 Page 20 

Art Unit: 2456 

whether push or pull. It would have been obvious to one in skilled in the art at 
the time of the invention to modify Adelman et al and Fleming to push or pull 
network information as taught in Rashid et al (see Page 3, Para 0036-0042 for 
push based process and Para 0043-0045 for pull based process) in order to 
implement authentication process and to provide subscriber with up-to-date 
information. 

Claim 16 is rejected under 35 U.S. C. 103(a) as being unpatentable over 
Adelman et al and Fleming in view of rfc2543. 

For claim 1 6 Adelman et al and Fleming teach all claim limitations except SIP 
message is being used as keepalive message. The general concept of using an 
SIP message as keepalive message is well known in the art as illustrated 
Internet draft session timer (page 3, second Para, "... this extension defines a 
keepalive mechanism for SIP sessions."). It would have been obvious to one 
skilled in the art at the time of the invention to modify Adelman et al and 
Fleming to use SIP message as keepalive message in order to create sessions as 
taught in RFC 2543 (RFC 2543, page 1, Abstract, first line, "The Session 
Initiation Protocol (SIP) is an application-layer control (signaling) protocol for 
creating, modifying and terminating sessions with one or more participants", 
which teaches SIP can be used to create sessions). 
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Claim 18 is rejected under 35 U.S. C. 103(a) as being unpatentable over 
Adelman et al and Fleming in view of Aharoni et al (US 6014694). 

9. Claim 21 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Adelman et al and Fleming view of Harsch and Rashid et al. 

For claim 21, Adelman et al, Fleming and Harsch (as discussed supra in claim 
20) teach all claim limitations, except polling the network load information 
from the controller. The general concept of polling information is in well known 
in the art as illustrated in Rashid: Figure 3, following item 302 to decide 
whether poll or push. It would have been obvious to one skilled in the art at the 
time of the invention to modify Adelman et al , Fleming and Harsch to poll the 
network load information in order to implement authentication process as 
taught in Rashid et al (Rashid: Page 3, Para 0043- 0045 for poll based process). 

10. Claim 23 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Adelman et al and Fleming in view of Harsch and Aharoni et al (US 6014694). 

For claim 23, Adelman et al, Fleming and Harsch teach all the claim limitations 
except keeping track of the network bandwidth. The general concept of keeping 
track of network bandwidth is well known in the art as illustrated by Aharoni 
et al (Aharoni: FIG. 12, sender keeping (calculating) track of bandwidth as 
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shown in the top start item). It would have been obvious to one in skilled in the 
art at the time of invention to modify Adelman et al, Fleming and Harsch to 
keep track bandwidth use in order to determine new time to send as taught in 
Aharoni et al. (see, Aharoni: FIG. 12/2, item 160). 

Conclusion 

ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the 
extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire 
THREE MONTHS from the mailing date of this action. In the event a first reply 
is filed within TWO MONTHS of the mailing date of this final action and the 
advisory action is not mailed until after the end of the THREE-MONTH 
shortened statutory period, then the shortened statutory period will expire on 
the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In 
no event, however, will the statutory period for reply expire later than SIX 
MONTHS from the date of this final action. 

Any inquiry concerning this communication or earlier communications 
from the examiner should be directed to Yasin Barqadle whose telephone 
number is 571-272-3947. The examiner can normally be reached on 9:00 AM 
to 5:30 PM. 
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If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Bunjob Jaroenchonwanit can be reached on 571-272- 
3913. The fax phone number for the organization where this application or 
proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained 
from the Patent Application Information Retrieval (PAIR) system. Status 
information for published applications may be obtained from either Private 
PAIR or Public PAIR. Status information for unpublished applications is 
available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access 
to the Private PAIR system, contact the Electronic Business Center (EBC) at 
866-217-9197 (toll-free). If you would like assistance from a USPTO Customer 
Service Representative or access to the automated information system, call 
800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



/Yasin M Barqadle/ 

Primary Examiner, Art Unit 2456 



